Traditional information technology (IT) architecture has relied on centralized computing structures, whereby all or most of the processing and computing is performed on a central server. Centralized computing can enable the deployment of central server computing resources, administration, and management. Typically, computational processing involves the extraction, transformation and loading of a resultant data feeds by the centralized computing structure. Security for data feeds is typically provided by securing the computational nodes.
However, cost and performance inefficiencies of centralized computing structures have steered IT architectures towards decentralized computing structures, whereby data feeds are extracted, uploaded to a decentralized computing platform and then transformed. Doing so provides cost and performance efficiencies since the infrastructure to perform the computational processing can be outsourced to an entity that specializes in such.
As decentralized computing develops, both the velocity and diversity of data can cause some security measures to have an impact on latency, scalability, and recovery performance. Security risk has evolved beyond solely the computational node and now includes network connections between those nodes. Thus, security can be viewed as a service constraint.
Security permissions are usually mapped to an object (system, file, database, etc.) and checked on subject request for operation via an Access Control Lists (ACLs). These ACL's are intended to support “authentication,” “authorization,” and “auditing.” However, in most modern enterprise systems these capabilities have become separated. For example, authentication is deferred to an “authoritative master;” in authorization, the permissions depend on the “objects in scope;” and in auditing, the logging specifics depend on the “events in scope.”
Because these security tasks have become functionally separated, the cost to keep them reasonably synchronous in a large enterprise often becomes so high that critical permissions maintenance and audit may not be performed. For example, the basic security on a file system may be statically mapped to folders and files. One either has the necessary permissions to list, read, write (accept) or one does not (deny). The subject is authenticated (e.g., mapped to a known principal) and authorized. Auditing occurs at the object level. However, the file system may be blind to the data that participates. One strategy to deal with this fundamental weakness is a multilevel classifications system (like Bell-LaPadula). However, such system still depends on static specifications.
Data may be classified by business sensitivity and risk controls, which in turn are factored into the permissions granted to an object. In this regard, subjects derive permissions to data based on their assigned clearance to the underlying secure data corridor. The data layer is now sensitive to the import, transformation, viewing and export of such data. A more modern form of the ACL would integrate risk and auditing. Such integration implies that metadata associated with risk controls and data sensitivity is stored in the security hive. As such, these decisions no longer reside in the application layer, but are verified and enforced at the system level.